Amazon SageMakerがどのような仕組みで動いているのか

じょんすみす

2018.05.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、小澤です。

今回はAmazon SageMaker(以下SageMaker)の機械学習でどんなことができるのか？ではなく、そういった実運用するに際してありがたい仕組みがどのように提供されているのかついて書かせていただきます。

なお、機械学習に関する話は出てこないので、その点はご了承ください。

今まで何が課題だったのか

さて、最初に機械学習を使ったシステムを実運用するに際してどんな課題があったのかを整理したいと思います。機械学習を使ったシステムの開発フローは以下のようになります(画像は過去に書いたブログからの転載)。

この中で大きく分けて「学習時のフロー」と「予測時のフロー」で必要となるスキルが異なります。「学習時のフロー」では機械学習そのものに対する専門知識が必要になります。これには

機械学習の手法そのものに対する知識
有効な特徴抽出に関する知識
適切な評価に関する知識

などが必要になるでしょう。これらは、データ分析に関する知見が必要になる要素となっています。

一方、「予測時のフロー」はシステムに組み込まれるものになっています。こちらは

システムにどのように組み込むかのアーキテクチャ設計
例外処理などを含めた本番で動かせるレベルのソースコード
本番環境で動かすためのインフラ周りの知識

といった要素が必要になるため、プログラマのスキルセットが必要になります。

機械学習システムではモデルの定期的な更新が必要になりますし、どのような予測を行うか人間が予想できないのでA/Bテストの実施なんかも必要になります。さて、そうなってくるといろいろ大変ですね。

そこでとっても嬉しい機能を提供しているのがSageMakerとなるわけです。

SageMakerの構成

では、SageMakerを構成する要素がどのようなものになっているのか見てみましょう。

SageMakerでは機械学習アルゴリズムの利用方法に関して

Build-Inの手法を利用する
TensorflowやMXNetを利用する
独自に開発したものを利用する

の3つがあるのでが、今回はBuild-Inの手法を利用するものをベースに解説します。それ以外の2つについては必ずしもここで記述した内容と同じ動きとはならない可能性がありますのでご注意ください。

Jupyter Notebookの利用

利用者は基本的にJupyter Notebook上で作業を行います。 Jupyter Notebookに関しては、以前にちょっとだけ解説した記事を書いているのでそちらもご参照ください。

データ分析を便利にするJupyter notebookとPandas ｜ Developers.IO

学習用コンテナの起動

学習の処理は先ほどのJupyter Notebookが起動しているインスタンスで行うわけではありません。 Notebookの中で学習処理を走らせると、学習用のコンテナが作成されそこで学習処理が実行されます。 SageMakerでは、学習に利用するコンテナ数を指定することで分散処理での学習が可能になっています。

作成するコンテナのイメージはJupyter Notebookで作成した内容に基づいて新たに作られるわけではなく、手法ごとに必要なライブラリがインストールされたイメージを利用しているようです。機械学習の手法自体はライブラリ化なども進んでいることからもわかる通り、汎用的に利用可能なものなので、学習データのパスやハイパーパラメータなど実行時に指定するパラメータのみを渡すことで実現可能なため、このような仕組みで実現可能となっています。

学習が完了すると、モデルがS3に出力されたのちコンテナは削除されます。

APIエンドポイントの作成

最後に学習済みのモデルを利用して予測を行うためのAPIの作成を行います。こちらもJupyter　Notebookからデプロイを行うだけで完結するものとなっています。

エンドポイントのAPIももちろんスケールさせることが可能になっています。

この仕組みだと何が嬉しいのか

さて、ではこのような仕組みになっているとどのように嬉しいのかについての話をしたいと思います。

まず学習時のことを考えてみましょう。ここは主にデータ分析者が利用するものとなっています。データ分析者にとって嬉しい点は

必要なライブラリがインストールされた環境がすぐに利用可能なので環境構築などのシステム面にかかる部分を気にしなくていい
Jupyter Notebookが利用可能なのでデータ分析者にとって慣れ親しんだ環境が使える

データ分析者はシステムの開発者とは異なるスキルセットを持っていることも多いので、これらの仕組みが提供されていることで本質的ではない部分での苦労が大幅に減ることになります。

続いて、予測時のことを考えると

APIとして提供されるので既存環境に影響を与えない
機能として実装する必要がないのでシステム開発者に依頼する必要がない

というメリットがあります。また、プログラミングに不慣れなデータ分析者が書いたコードもこのAPIには含まれていないため、本番運用でもそのまま利用可能です。 REST APIのエンドポイントとして提供されるため、既存の環境と疎な結合となり、バージョン管理を含むモデルの定期更新の管理やA/Bテストなども容易になります。